3 subject="""comment 1"""
4 date="2023-03-28T18:35:23Z"
6 Looking at the code, handleRequestExport first uses
7 withExternalState to send EXPORT, and then it calls
8 handleRequestKey to send the following command. That uses
9 withExternalState a second time.
11 withExternalState operates on a pool of processes, so in a race
12 (when using -J presumably, as your test case does), the two
13 calls to it can use different externals. And so the bug.
15 Was easy to fix based on that analysis. I have not tried to reproduce it,
16 but am confident that I fixed it in
17 [[!commit 02662f52920e84cd9464641ada84f6c3bbe3f86a]]
21 In your implementation, you're keeping EXPORT set after handling TRANSFEREXPORT
22 and similar commands, and so if you receive a TRANSFEREXPORT not prefixed by an
23 EXPORT, it can be bad. A natural way to write things, indeed
24 `doc/special_remotes/external/example.sh` does the same.
26 An alternative implementation would be to clear the EXPORT after handling a
27 TRANSFEREXPORT, CHECKPRESENTEXPORT, REMOVEEXPORT, or RENAMEEXPORT.
28 And have those error out if no EXPORT was received before them.
30 But, that does not fully avoid the data loss problem. Because this might
35 TRANSFEREXPORT STORE $foo_key $foo_file
37 So even ignoring the first EXPORT can result in the external special remote
38 doing the wrong thing. To fully guard against it, you'd have to error out
39 if multiple EXPORT were received before a request that uses one, rather
40 than ignoring the first EXPORT.
42 So, fixing this in your remote and others would need significant defensive
43 coding. Too much to make sense, IMHO. I think git-annex needs to chnge the
44 protocol in some way instead, to make it easy for you to avoid speaking to